A multitude of different types of communication terminals or devices have been developed for packet-based multimedia communication using IP (Internet Protocol). Multimedia services typically involve transmission of media in different formats and combinations over IP networks. For example, an IP-enabled mobile terminal may exchange media such as visual and/or audio information with another IP-enabled terminal, or may download media from a content server over the Internet.
A network architecture called IMS (IP Multimedia Subsystem) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling and controlling multimedia services and sessions, commonly referred to as the IMS network. Thus, an IMS network can be deployed to initiate and control multimedia sessions for IMS-enabled terminals connected to various access networks, regardless of the access technology used. Although conceived primarily to enable multimedia services for mobile IP terminals, the IMS concept can also be used for fixed IP terminals.
Multimedia sessions are handled by specific session control nodes in the IMS network, e.g. the nodes P-CSCF (Proxy Call Session Control Function), S-CSCF (Serving Call Session Control Function), and I-CSCF (Interrogating Call Session Control Function). Further, a database node HSS (Home Subscriber Server) is used in the IMS network for storing subscriber and authentication data. The IMS network may also include various application servers for providing different multimedia services.
According to the IMS platform, the protocol for controlling sessions called SIP (Session Initiation Protocol) is utilised to initiate, operate and terminate multimedia sessions. Standard SIP messages can thus be used by IP terminals or devices for establishing multimedia sessions, such as the session initiating message “SIP invite” and the common response message “SIP 200 OK”.
In SIP, an SDP (Session Description Protocol) can also be used, embedded as a self-contained body within SIP messages, to specify different communication parameters needed for a forthcoming multimedia session. This protocol is generally used to provide necessary information in session setup procedures, e.g. device capabilities, media properties, currently used IP addresses, etc., as is well-known in the art.
It is desirable to generally provide IMS-based services also for devices in a limited local or private network such as a residential or office network, also referred to as a LAN (Local Area Network) or PAN (Personal Area Network). In this description, the generic term “local network” is used to represent any such networks, and the term “device” is used to represent any terminal capable of IP communication within a local network. In such local networks, a local IP address is allocated to each device for communication within the network which, however, cannot be used for routing messages and data outside that network.
The devices in a local network may include fixed and wireless telephones, computers, media players, servers and television boxes, the latter often referred to as STB (Set Top Box). In order to provide IMS services for devices in the local network, a multimedia gateway called HIGA (Home IMS Gateway), has been defined that can emulate an IMS terminal from the local network towards the IMS network, to access IMS services on behalf of any device in the local network. The HIGA has valid IMS identities known to the IMS network, such as an IMPI (IMS Private Identity) used for authentication and at least one IMPU (IMS Public Identity) associated with an IMS service profile. In WO 2006/045706 A1 (Ericsson) it is described how devices in a local network can obtain IMS services by means of a HIGA using different IMS identities IMPU.
UPnP (Universal Plug-and-Play) is an architecture, developed in a multi-vendor collaboration called the UPnP Forum, for establishing standardised device protocols for the communication between different IP devices in a local network using different access technologies, operating systems, programming languages, format standards and communication protocols. UPnP further provides standardised methods to describe and exchange device profiles that may include capabilities, requirements and available services in the devices.
UPnP and other protocols also supports a process called “discovery” (or “pairing”) in which a device can join a local network, obtain a local IP address, announce its name and IP address, and exchange capabilities and services with other devices within the network. In the following description, the term “discovery information” generally represents any such information such as name, identity, local IP address, URI (Universal Resource Identifier) for stored media content, device capabilities and available services, communicated between the devices during the discovery process. The discovery process can also be conducted within a temporarily formed ad-hoc network, e.g. using Bluetooth communication. Specific service discovery protocols have been standardised for finding devices and their services in the discovery process.
DLNA (Digital Living Network Alliance) is a recently developed technology for acquiring, storing and accessing digital media content from devices in a local network. The UPnP protocol is utilised by DLNA as an underlying protocol for communication between devices within local networks.
An architecture for enabling remote access will also be defined, where remote “UPnP devices” located outside the local network can communicate media with devices within the network. In WO 2006/079891 A1, a solution is described for setting up a VPN (Virtual Private Network) tunnel as a data/media transport channel for such remote UPnP access, e.g. using IPSec (IP Security). However, this solution requires the use of IP address resolution and DNS (Domain Name server) technology, as well as access to a dynamic DNS client in the private network.
There are also some so-called “vertical” solutions available for remote access to home appliances, services and media in a local home network, such as Slingbox, LocationFree, Orb and Soonr. However, it is a problem that these vertical solutions are not standardised and therefore not desirable to use for service providers and network operators, e.g. due to added complexity and limited control. For example, a network operator would then merely act as a “bit-pipe” with no ability to control issues like security, routing, charging and quality-of-service QoS. A standardised “global” solution for remote access would thus enable a more extensive market for this type of services and generally improved services as perceived by end users.
In FIG. 1, a local network 100 is shown with different devices in a family residence or an office. In this example, these devices include a wireless telephone, a fixed telephone, a TV apparatus, a laptop computer, and a media server. The network 100 also includes a conventional gateway 102 connected to an external access network 104 to provide a communication link outside network 100 for the devices, referred to as RGW (Residential Gateway). Although not shown in this figure, the RGW 104 typically includes an NAT (Network Address Translation) function for the mapping of port numbers and IP addresses, and a local DHCP (Dynamic Host Configuration Protocol) server allocating local IP addresses to the devices, as is well-known in the art.
The local network 100 further includes a HIGA 106 providing a connection to an IMS network 108 in which an HSS 110 is shown. The HIGA 106 has different suitable interfaces towards the different devices in network 100, using device-specific protocols. The HIGA 106 may be integrated in the RGW 102, but logically it will be considered as an individual functional unit in this description.
The HIGA 106 holds IMS identity information 112 associated with IMS subscriptions and user/service profiles, such as the above-mentioned IMPI and IMPU, which can be used for accessing the IMS network 108 where corresponding subscriber information 114 is stored in the HSS node 110. Accordingly, a user can log on to the IMS network from a specific used device in the local network 100 by means of HIGA 106, and the local IP address of that used device will then be associated with the user profile.
When HIGA 106 receives a request for a multimedia service from a device in network 100 using a device-specific interface/protocol, HIGA 106 translates the service request into a valid IMS request (typically a SIP invite message) to set up an IMS session on behalf of the device, involving the communication of suitable SIP messages with the IMS network 108. In a similar manner, HIGA 106 can set up an IMS session when receiving an incoming request for a session with a device in the local network 100, by using an IMS identity 112 associated with the device. In either case, communicated media is routed during the session from or to the device over the RGW 102 and the access network 104, as indicated by two-way arrows.
FIG. 1 further illustrates that a local device 100a moves outside the local network 100 thereby becoming a remote device 100a′. The remote device 100a′ can then send a SIP invite message to the HIGA 106 over the IMS network 108, to initiate media communication with one of the remaining devices in network 100. In order to do that, the remote device must be an IMS client and use a valid IMS identity for accessing the IMS network.
The above-mentioned DLNA technology also provides for the so-called “3-box model”, where a first device can be used for controlling the transfer of media from a second device to a third device within a local network. For example, a small handheld wireless phone may be used as a control unit to direct a laptop computer to stream visual media content to a TV set, in order to view the content on a larger screen and with greater quality as compared to the laptop computer. The TV set is then used as a “media renderer”.
However, it is a further problem that no solution is available for applying the 3-box model when the terminals are located in different local networks. It is thus not possible today to remotely control a media transfer across different local networks, for example to direct a device in one local network to communicate media content with a device in another local network.